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ABSTRACT 



A computer-implemented method and system for allowing 
Java classes to be shared among many Java virtual machines 
(JVMs) including a communication system allowing Java 
and native applications to readily intemperate. An imple- 
mentation of the JVM on an operating system platform, e.g., 
the Aperios AV/OS, allows a variety of applications includ- 
ing desktop applications, applets and Internet based 
applications, home networking applications, MHEG-6 
applets, gaming, gaming applications and next generation 
audio visual applications to operate with the operating 
system. The present invention provides a shared memory 
pool (SMP) into which a JVM and store and register a 
particular Java class. The stored and registered Java class is 
then accessible by other JVMs using the SMP and a Java 
layer class manager that is implemented in software. The 
Java layer class manager requires other JVMs to access a 
key for the stored class in order to synchronize access to the 
Java class among several installed and operating JVMs of 
the computer system. By sharing common Java classes in 
this fashion, the memory resource overhead required to 
operate multiple JVMs on a common computer system is 
drastically reduced thereby allowing a multiple JVM plat- 
form to be operable on an embedded computer system. A 
novel communication method is also disclosed for commu- 
nicating information between a JVM application and a 
native application using the computer system's operating 
system. The novel communication method also allows mul- 
tiple JVM applications to communicate using the shared 
memory pool. These functions are incorporated into a Java- 
Layer that supports the full PersonalJava™ platform. 

20 Claims, 13 Drawing Sheets 
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FIGURE 5 
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FIGURE 6 
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COMPUTER-IMPLEMENTED SHARING OF Each JVM installs, into memory, its own copy of the Java 

JAVA CLASSES FOR INCREASED MEMORY classes which are required to allow the respective JVM to 

EFFICIENCY AND COMMUNICATION operate. For instance, JVM 11 installs classes 21 for its own 

METHOD use, JVM 12 installs classes 22 for its own use, JVM 13 

5 installs classes 23 for its own use and JVM 14 installs 

RELATED US APPLICATION classes 24 for its own use. However, many of the installed 

Hie present application claims priority of U.S. Provi- J f Va ^ aSSCS are ? pi f of lhe same class > ^ class A and 
sional Patent Application Ser. No. 60/108,468, filed Nov. 14, ™» B are copied and are individually used by many of the 
1998, entitled "JavaLayer: A framework for Implementation J ™ s ' 7** Size of the ^ ass <*> *nd fact that each JVM 
of PersonaUava on Aperios Audio Video Platform (AV/ 10 needs lts own C0 W> makes lt ver y difficult t0 run multiple 
OS)/' by Qiaoyun (Liz) Li. JVMs simulta neously on a single computer system. This is 

especially true for embedded computer systems which lack 
BACKGROUND OF THE INVENTION robust me mory resources. What is needed is a system and 

method for allowing efficient use of memory resources when 

1. Field of the Invention 15 operating Java on a dedicated environment. 

Irie present invention relates to the field of software Moreover, when Java systems are running on dedicated 

architectures for a computer system running multiple Java environments, there is presently no effective way to pass 

Virtual Machines (JVMs). More specifically, the present messages between native applications and JVM applications ( *3 * 

invention relates to a software architecture that can be used or between two or more JVM applications. What is needed , 
for audio/visual digital devices including embedded sys- 20 fe a systcm and mcthod for aUowing efficicnt mcssagc KcA'V«X>-^ 

lems * passing between native applications and JVM applications, 

2. Related Art or between two or more JVM applications, within a dedi- 
Many computer operating systems require Java for vari- cated environment. 

ous applications including home networking applications, 

MPEG applets and other desktop and Internet applications. 25 SUMMARY OF THE INVENTION 

aZ r/^H h0n r C , netW ° r K^ * PpUc f ion is to < Homc Accordingly, the present invention provides a system and 

r!? H^^ ty) ^^ ^ iD 3 mCth0d for aUowin B ^ent use of memory resources when 

eference entitled "HAVI: an T architecture for interoper- operating Java on a dedicated environment e.g., an embed* 

£Se"S 7 °^ "? r™ 0 30 ded computer system or other mtemgenteiecLic device. 

SSi ™ It . ? f a ba t ck e roUDd « GlveD ^ present invention further provides a system and method 

t Si??? P T a PP hcatl0DS caD for allowing efficient message passing functionality between 

LlSio? T°7 I'' °r Dg SyStCmS ' 1 1 b0th - IT DatiV6 ■PPlications and JVM applications, and between two 

™2T h h^k ?d TOn /™« u c ^nics or more JVM applications, within the dedicated environ- 

markets, it is desired Uhat PersonaLJava (pJava) be supported m ent. Specifically, what is disclosed herein is a novel class 

on various types of devices such as, for instance, set-top sharing model for minimizing the ^^SS^ 

SST m digital teIevi " multiple JVMs on a " edicated 

w 1 i. • , . C S » an embedded system. Embodiments of the present 

Moreover, the implementation of the standard Java Vir- invention also include a model for mapping different physi- 

tual Machine (JVM) on personal computers (PCs) or on 40 cal devices installed with their own file management and a 

workstations allows applications to be developed in Java by model for external applications to communicate with Per- 

programmers who do not necessarily understand the oper- sonalJava. 

ating system of the host computer system. In one example, , t 0 reduce the menwv f™,,^* „f T vx/ 

Java classes to be shared among many Java Virtual 
Machines (JVMs) and this system includes a communication 
system allowing Java and native applications (or two or 
more JVM applications) to readily interoperate. Various 

.0 port PersonaUava to the Aperios's AVIOS envkonm^ I tZTctls^vL^wTT' ™ 

sunnnrt A«H n V,!t Ta * eiS °° aIJ * Va do< ?. n , ot L ' AVAa very attractive platform for applications. A software 
support Audio Video (AV) applications, which need more framework described herein, referred to as "JavaLayer " (or 

flexible functionality to adequately handle certain function- Java layer) allows various coexisting applications to share 

a hty such as volume data handling and transfer, device and 55 resources and provide an optimal run-time environment The "~1 

stream control management, message passing, event man- JavaLayer enables Java and native applications to interop- 

agement and communication with native applications. erate easily, manage class sharing and aids by efficient 

Therefore, it would be advantageous to design and build a garbage collection. ™ I 

dedicated environment for the implementation of a Java An imnlemenmtmn n f th. tw\a ~ .• 

sys^m infras^cture which would help AV applications. 60 SSs? SSTSS^ ^ 

THere are other problems with respect to running Java applications including desktop applications, applets and 

f" vlron ™ n,s ' «*• an ""bedded Internet based applications, home networking applications, 

computer system or other intelligent electronic device. MPEG applets, gaming, gaming applications and next gen- 

Namely, embedded computer systems do not have the eration audio visual applications to operate with the oper- 

™™V nonces turned to support Java systems. FIG. 1 65 ating system. The present invention provides a shared' 

illustrates a software architecture where a single computer memory pool (SMP) into which a JVM can store and register 

system is running multiple JVMs 11-14 simultaneously. a particular Java class for subsequent use by itself or by 



system available from Sony Corporation. Because Aperios' 
AVIOS is a highly configurable, real-time and micro-kernel 
platform, it would be advantageous that highly compact and 
memory efficient implementations of the JVM be imple- 
mented on top of it. For instance, it would be advantageous 
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other JVMs. The stored and registered Java class is acces- memory pool and the JavaLayer class manager to share 

sible by other JVMs using the SMP and a Java layer class classes between multiple JVMs. 

manager (JCM) that is implemented in software. The JCM FIG. 11 illustrates a logical diagram of real-time coordi- 

requires other JVMs to access a key for the stored class in nat i 0 n between native applications and a JVM in accordance 

order to synchronize access to the Java class among several 5 ^th mc mcssag c transfer method of an embodiment of the 

installed and operating JVMs of the computer system. By present invention 

sharing common Java classes in this fashion thememory FIG. 12 illustrates a logical diagram of real-time coordi- 

resource overhead required to operate multiple JVMs on a natk)n bctwccn JVM f fa acC( f rdancc ^ thc mcssagc 

common computer system is drastically reduced thereby t f tU A e . ^^uw wnu m^Mgc 

allowing a multiple JVM platform to be operable on an 10 tr ^ sfer m ethod of an embodiment of the present invention, 

embedded computer system FIG - 13 illustrates a timing diagram of events of the 

A novel communication method is also disclosed for ^ordination between two JVMs in accordance 

communicating information between a JVM application and Wth ^ meSS . age transfer method of an ^dimcnt of the 

a native application, or between two or more JVMs, using P resen invention. 

the computer system's operating system and the SMP. The 35 DETAII ED DFSCRTPTTON DF THP 

novel communication method allows multiple JVM appli- UUlAlLbU ^ E ™ P ™ N 0F ™ E 
cations to communicate using the shared memory pool. 

These functions are incorporated into a JavaLayer that In the following detailed description of the present 

supports the full PersonaUava™ platform. invention, a computer-implemented method and system for 

More specifically, in a computer system having a proces- 20 snar ing Java classes across multiple Java virtual machines 

sor coupled to a bus, a memory device coupled to the bus on ^ same computer system and a method for communi- 

and a display screen coupled to the bus, embodiments of the cation between Java and native applications (or between two 

present invention include a method of sharing Java classes or more JVMs), numerous specific details are set forth in 

comprising the steps of: a) a first Java Virtual Machine order to provide a thorough understanding of the present 

(JVM) loading an instantiation of a first Java class into a 25 invention. However, it will be recognized by one skilled in 

shared memory pool; b) registering a name of the first Java tne art tnat mc present invention may be practiced without 

class into a name table for the shared memory pool; c) a f Dese specific details or with equivalents thereof. In other 

second JVM querying the name table to determine if the first instances, well known methods, procedures, components, 

Java class is stored in the shared memory pool, wherein the m & circuits have not been described in detail as not to 

second JVM is operating on the computer system simulla- 30 unnecessarily obscure aspects of the present invention, 

neously with the first JVM; and d) the second JVM access- The following documents are referenced as background 

ing and utilizing the instantiation of the first Java class from material and as such are incorporated herein by reference: 

the shared memory pool in lieu of creating a separate Aperios™ v.1.1.1 User Guide, Sony 1998; "HAVI: an IT 

instantiation of the first Java class for its own use. architecture for interoperability in the home network," by 

RRTFF nPSPRTPTTHM HP TUC no awtnt^c ^ R ° dgCr U * ™ d MTOn Ludtke > SRF97 > ' <The Java Actual 

BRIEF DESCRIPTION OF THE DRAWINGS Machine Specification," by Tim Lindholm & Frank Yellin, 

FIG. 1 illustrates a prior art software configuration of Java Addison Wesley, 1996; and "With HotSpot, the JVM is 

virtual machines (JVMS) including each JVM having its ^ aster tnan a speeding bullet," by Eric Armstrong, 

own separate memory allocation for Java class storage. 40 J *vaWorld, Mar. 25, 1998. 

FIG. 2 illustrates a general computer system utilized in Embodiments of the present invention include a dedicated 

accordance with an embodiment of the present invention. framework, called JavaLayer, that allows various coexisting 

FIG. 3 is a logical block diagram of the system architec- applications to share resources and provide an optimal 

ture of the computer system used by the present invention run-time environment. The JavaLayer enables Java and 

HG. 4 is a logical block diagram of the JavaLayer 45 native a PP]ications to intemperate easily, manages class 

software model used by the computer system of the present * h anng and a1 ^ efficient garbage collection. It also allows 

invention or more «rvMs to interoperate. In one embodiment, 

invention including .he metaspaces with which it interoper- 50 A ™ P^nn allows a variety of applications 

ates y including desktop applications, applets and Internet based 

u,r t- ,u i • , ui , _■• r , » . applications, home networking applications, MPEG-6 

HG. 6 is another bgical block diagram of the JavaLayer applets, gaming applications and netf generation AV ori- 

arcm tecture supporting multiple applications on one JVM Jed applications to run on Aperios f rio4 feamL of 

ZSSS™, aCC ° " 6mb0diment ° f 55 Java ®* ° nc6 > ™ everywhere", compactness, stan- 

present inventions dardized ^ and ^ avajlability of advanced M ^ aU 

MG. 7 is a block diagram of the JVMs interfacing with the make this platform very attractive for applications, 
shared class memory pool of the present invention using the 

JavaLayer class manager. Notation and Nomenclature 

FIG. 8 illustrates the physical and logical memory orga- „ . * ,u j . •, j . ... L . , „ , 

nization of the class sharing system of the presen. invention. Jl™S£ , detailed descriptions which follow 
mr o -Ik. . , i c i 1 . 7, " are presented in terms of procedures, steps, logic blocks, 

mem?n,^?™^™n^f le0 ^ C ^ Sha^m ^ 0f ^, Cl,,SS P^^ing. and omer symbolic representations of operation 
memory pool across muluple applications using the Java- 0 n data bits within a computer memory. These descriptions 

mvention 58 """"^ ( } m ^ ^ ^ ^ aDd re P resentati ™ ™ «» «ne»a used by those Sd m 

A . 65 the data processing arts to most effectively convey the 

FIG. 10 is a flow diagram illustrating steps of the class substance of their work to others skilled in the art A 

sharing process of the present invention using the shared procedure, computer executed step, logic block, process, 
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etc., is here, and generally, conceived to be a self-consistent communicating user input information and command selec- 
sequence of steps or instructions leading to a desired result. tions to the central processor 101, The cursor directing 
The steps are those requiring physical manipulations of device 107 can be implemented using a number of well 
physical quantities. Usually, though not necessarily, these known devices such as a mouse, a track ball, a track pad, an 
quantities take the form of electrical or magnetic signals 5 electronic pad and stylus, an optical tracking device, a touch 
capable of being stored, transferred, combined, compared, screen etc. Computer system 112 can also include an 
and otherwise manipulated in a computer system. It has optional signal generating device 108 coupled to the bus 100 
proven convenient at times, principally for reasons of com- for interfacing with other networked computer systems. The 
mon usage, to refer to these signals as bits, values, elements, display device 105 utilized with the computer system 112 is 
symbols, characters, terms, numbers, or the like. 10 optional and may be a liquid crystal device, cathode ray tube 
It should be bome in mind, however, that all of these and (CRT)> light emitting diode (LED), field emission device 
similar terms are to be associated with the appropriate (FED, also called flat panel CRT) or other display device 
physical quantities and are merely convenient labels applied suitable for creating graphic images and alphanumeric char- 
to these quantities. Unless specifically stated otherwise as acters recognizable to the user, 
apparent from the following discussions, it is appreciated 15 

that throughout the present invention, discussions utilizing System and Software Architectures 

terms such as "processing- or "computing or "translating" FIG . 3 mustrates a tem architecture 120 that can be 

or ^calculating or determining" or "scrolling" or "display- installed within the computer system 112 (FIG 2) The 

ing or recognizing" or the like, refer to the action and present mvention inchldes a shared mem ^ (SN / p) and 

processes of a computer system, or similar electronic com- ™ JavaLayer class Manager (JCM) for allowing registered 

puting device, that manipulates and transforms data repre- Java classcs to bc Amd ^ mm?lc j ava virtual 

sented as physical (electronic) quantities within the com- Machines (JVMs) that simultaneously run on the system 

puter system s registers and memories into other data m . By sharing basic Java classes, in lieu of maintaining a 

similarly represented as physical quantities within the com- separate copy of each class for each JVM, the present 

puter system memories or registers or other such informa- 25 ^ tQ bcttcr ^ sources fonhc 

tion storage, transmission or display devices. embedded computer system m A as dQ&M 

Computer System 112 m ° rC ^ bclow > stains both definitions and data and is 

y implemented using Java byte codes which can be read by a 

Aspects of the present invention, described below, are 30 * ava interpreter. Byte codes are machine independent so that 

discussed in terms of steps executed on a computer system, tne y can ^ e executed on any machine, 

also called embedded system, (e.g., process 410 of FIG. 10) Within the system architecture 120 of FIG. 3, the API 

for sharing Java classes. Within the present invention, the layer 125 or application program interface is shown as the 

computer system can be integrated within a portable elec- top layer. The API 125 is associated with a JVM 130. 

tronic device or system, e.g., a personal digital assistant, a 35 Generally, only one application is resident for a particular 

portable computer system (e.g., a laptop, a palm sized JVM 130. The device module 135 includes a file system 

device), a portable consumer based electronic device such as which can use a mini disk, a hard disk, flash ROM a 

a mobile phone or car navigator. As an embedded system, CD-ROM and/or a tape storage device. Resources that are 

the computer system can also be used as part of an Internet shared 140 include hardware devices, methods, memory and 

television system, a set-top box (STB), within a printer, in a 40 Java classes that are stored in memory (e.g., the shared 

digital video disk (DVD), an industrial controller, a tele- memory pool). Communication 145 is performed using the 

phone or within an instrumentation device. Although a Dispatcher, Java Native Interface (JNT) and a Wrapper. At 

variety of different computer systems can be used with the the bottom layers are located an operating system (OS) 150, 

present invention, an exemplary general purpose computer e.g., the Aperios AV/OS, and a device driver 155 

^^^^' m ^ Q ' 2 '^^^^^ 45 FIG. 4 is a logical block diagram of the JavaLayer 
as a software platform of system 112. software architect J* re m of me co g mputer system {q J£ 

In general, computer system 112 of FIG. 2 includes an dance with an embodiment of the present invention. At the 

address/data bus 100 for communicating information, a top layer is the application 170, e.g., a HAVi application an 

central processor 101 coupled with the bus for processing MHEG application, etc. Between the application 170 andthe 
information and instructions, a volatile memory 102 (e.g., 50 associated JVM 130 is located the interoperability API 125 

random access memory RAM) coupled with the bus 100 for At layer 175 is the event, mapper and communication 

storing information and instructions for the central processor portions of the JavaLayer 175. The device module can 

101 and a non-volatile memory 103 (e.g., read only memory include a set-top-box 180. The operating system is shown as 

ROM) coupled with the bus 100 for storing static informa- layer 150. The device drivers can include a board driver 182 

tion and instructions for the processor 101. Computer sys- 55 and a serial communication driver, e.g., a 1394 board 184 

tem 112 also includes a data storage device 104 ("disk Although one JVM is shown in FIG. 3 and FIG. 4, multiple 

subsystem") such as a magnetic or optical disk and disk JVMs are supported in accordance with the present inven- 

dnve coupled with the bus 100 for storing information and tion. 
instructions and a display device 105 coupled to the bus 100 

for displaying information to the computer user. System 112 60 Shared Memory Pool for Sharing Java Classes 

can also be referred to as an embedded system. Between Multiple JVMS Running Simultaneously 

Also included in computer system 112 of FIG. 2 is an FIG. 5 illustrates the JavaLayer 160 and the metaspaces 
optional alphanumeric input device 106 including alphanu- with which it interworks. This architecture supports multiple 
menc and function keys coupled to the bus 100 for com- JVMs simultaneously within the same computer system 112 
mumcating information and command selections to the 65 For instance, JVMs 224 and 130 are simultaneously sup- 
central processor 101. System 112 also includes an optional ported. As shown, each JVM interacts with certain Java 
cursor control or directing device 107 coupled to the bus for classes 222, 226 and 228. The arrows show the direction of 
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communication between objects and the dash-lined boxes maintaining the Java classes through class sharing and for 

illustrate the relationship boundaries for the application providing mapping model to map different physical devices 

programs. When implementing a Java environment on an using their own file systems and file management APIs, 

audio video platform, developers have to deal with the Furthermore, a facility is provided which allows native 
features of the JVM 130, Java classes, and audio video (AV) 5 applications to communicate with PersonalJava. As FIG, 5 

media applications. The JavaLayer framework supports the depicts, the applications 222-228 running on JVM can 

application implementor in all the areas of Java and AV communicate with each other as well as with applications 

media applications. The framework consists of a set of 216-220 running on mAV 230 by using a combination of 

constructs and rules regarding the use of the constructs. The message passing and shared memory, 

constructs are a combination of C++classes, Aperios active with reference to FIG. 7, the shared memory pool 280 is 

objects and Aperios meta objects Other applications shown interacting with a JavaLayer Class Manager (JCM) 

S?i n IT" ° n ? ^ ^ mCt T Ce *°- 270 and a shared lock 260 ' ™» » JVM initializes its class 

HO. 6 illustrates another architecture used for memory- Hbrary, the JCM 270 uses the shared lock 260 to serialize 

limited devices. access tQ (he shsLrtd memorv p00 i 280, also called the class 
Specifically, FIG. 6 illustrates the JavaLayer 160 and the J5 poo l 280. The shared memory pool 280 is an area of memory 

metaspaces with which it interworks. The architecture of that is established for storing Java classes and other infor- 

FIG. 6 supports multiple applications 222-228 (Java byte mat ion to be shared across multiple JVMs which are running 

code classes) on one JVM 130 simultaneously. The arrows simultaneously on system 112. In this way, the shared lock 

show the direction of communication between objects and 260 is used by the present invention for serializing access of 

the dash-line boxes represent the application boundaries. shared Java classes between multiple Java applications 

Also shown are applications 216-220 running on mAV 256-258. 

metaspace 230. Using ^ shared memory poo j 280 of FIG. 7, a number 

Jne JavaUyer 160 supports two architectures as shown in of JVMs 251-253 can then access the same hbrary for 

. f- • I • JavaLa y cr 160 mns in toe mAV different operations without requiring that a separate, indi- 
metaspace 230 in Aperios operating system vl.l. In Aperios, ^ vidual copy of the Java class be stored for each JVM as done 

mDnve layer 232 is the metaspace that support device i n the prior art. In practice, the Java classes that every 

drivers and handles interrupts and mAV metaspace 230 is the application needs for operation are loaded in the shared 

metaspace for AV applications. Libranes in the mAV memory pool 280 in one memory space. Every block of that 

metaspace (which implement the JavaLayer 160) can com- memor y space has a lock down (shared lock 260). If a JVM 
mumcate wiUi drivers in the mDnve metaspace 232 for 30 wants to access the stored Java class in the shared memory 

storage, display and other devree functions. In accordance pool 280, then it must first obtain the lock associated with 

with the present mvention, when a class ,s loaded by a Java the desired Java class. Some of the basic Java classes to 

Placed in common space (t g the shared memory pool) and class, for example, Java 10, Java language, and Java beans 
JavTv^lXnl? u- Sh0Wn f iD 5 ' 35 Which can ^ haV6 ^her classes inctoded within. Some of 

wShU en ^T tT, ^T 8 f ° r u deV1CCS 111686 Java classes can as much « 2 Megabytes of 

which have enough memory FIG 6 shows the architecture memory each . m es6 Java classes mntaia basfc da & *J 

which supports multiple appl.cations running on one JVM for Java. In some other programming languages, apXom 
130 snnultaneously for memory-limited devices. In accor- Java, classes are referred to as libr Jies. 

dance with the present invention, a platform is described that , n p?™.«^ i_ • i , 

aUows multiple JVMs to run on a memory limited platform *° J° Tat^H and moving a 

tt j j , t . , 7 *u yiauuiiii. class is avoided as much as possible during operations 

"The JavaLayer framework is used to support JVM for Therefore, all classes 290-296 are managed by th centrd 

S2? %t C < / Sh n g , the r b3SiC C \ 3S& r m ,° ry ' JCM 270 meta -° b j 6Ct which ««»8" ^ memory pool 280 

meit on a W» 1 " ^T' ? deVebp - ° f class 06115 hold a " class "^ory. ™* memory pool 

u„l Ape T' 4 m ° r I , flCMble t" d alU ; aC u UV6 45 280 15 shared between tte multiple JVMs 251-253 and all 

development environment is provided and a shorter debug- JavaLayer modules as shown to FIG. 7 The JCM 270 

gmg phase is allowed mainly due to the features of the allocates memory to the classes within the shared memory 

!Sh \ ™£ 15 P T a ,^ p6 r DalJaVa P° 01 280 and divides toe shared memory pool 280 into 
pJava) but i can also be any other embedded JVM written blocks for this purpose. The individual blocks are then 

J^LuTtilo^K ^Awni™ ^ CaD mn mUltiplC 50 manag6d ^ toe JCM 270. If a JVM wants to share a class, 
JVMs simultaneously on AVIOS. it firet checks wi(h ^ JCM m ^ ^ references ; 

Herein, a JVM is a virtual machine which contains an name table and the lock for the class. The JCM 270 then 

execution space an execution engine, a class loader and a forwards the address of the class to the requesting JVM 

Java stack. A JVM can share classes and potentially an when the lock is free. The JVM can then access the shared 

initialization stack with other JVM or create its own initial- 55 Java class 

Si 5 ™ 'yP^VP™ 165 on Java b r* As shown in FIG. 7, an application can be associated with 

Acreated JVM can run several Java applications m parallel each JVM. As shown, application 256 is associated with 

1 r 7 ? ^ deSle T d la n f ditioa ' ^ JVM *»• a PP Ucati °n 257is associated with JVM 252 and 

JVMs In 1^, n ^ k VM 10 T n ° applica,ion 258 fe associated ^ JVM 253 - Re q« e ^ from 

^ potenhally deploy different garbage coUection 60 the JVM to access Java classes 290-296 are processed by the 

nd downloading mechanisms for different application. The JCM 270. Ashared lock 260 used so that only one JVM can 

JavaLayer framework supports a set of APIs with which access any particular Java class at any time In one 

apphcations can create a JVM, initialize a shared or non- embodiment, each Java class stored in Jsbared mernor^ 

nerfni f & class loader P™\ 280 has a read lock and a write lock. Typically, a Java 

perform event handling for special devices. 65 class is writteQ by omy one JVM> ^ 0 nJnMo t OI 

What is disclosed herem is a class management model for initiator JVM, and then can be read (e.g. shared) by the 
minimizing the amount of memory required for storing and other JVMs once the associated read lock is obtained Once 
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a class is written into the shared memory pool 280, it The JavaLayer guarantees the thread which holds the WL 

becomes registered with the JCM 270 within a name table. not being blocked or suspending before it releases the WL. 

The JCM 270 can then use the name table to respond to JVM Therefore, access to a JVM to write a Java class to the shared 

initiated requests for access to particular Java classes. memory pool 280 is managed by the JCM 270 using 20 the 

The JavaLayer framework offers APIs to the JCM 270 for s write lock. Access to read a stored Java class from the shared 

JVMs to perform operations on various classes and access memory pool 280 is managed by the JCM 270 using the 

the memory contents of the classes. The JavaLayer assumes shared read locks 260. 

a basic container, called class cells, that is used to support FIG. 9 illustrates that any access to the shared memory 

class loading. Class cells are dynamic memory buffers, pool 280 by the application 334 goes through the associated 

shared by JVMs in a shared mode, and used for class ™ JVM 251 for that application. The JVM 251 then accesses 

manipulations avoiding physical copying of class as much as the JCM 270 which manages access to the shared memory 

possible. When physical drivers and application objects use pool for the Java classes 290, 292 that are stored therein 

the same class cells they can share the class cell and FIG. 10 illustrates steps in a process 410 used by the 

effectively result m a JVM architecture that does not contain pre sent invention for sharing Java classes of the shared 

C0 P* CS * 1 memory pool. At step 412, a particular JVM, e.g., JVM(I), 

FIG. 8 illustrates physical and logical memory organiza- requests and obtains the write lock (e.g., "write key") (WL) 

tion of the classes within the memory pool 280. To avoid the to write a class, e.g., class(N), into the shared memory pool, 

physical copying and moving of classes when operations are The WL is managed by the JavaLayer class manager (JCM) 

performed on the classes by multiple JVMs 251-253, these When the WL is granted to JVM(I), then at step 414, it writes 

classes are stored in memory 310 in the manner as shown in 20 class(N) to the shared memory pool and the JCM registers 

FIG. 8. The class is stored in variable sized class cells or the class name into the name table and then links the table 

"blocks" 290-294. The actual class is constructed by linking entry with the proper offset and size in memory so that the 

cells together at certain offsets in the class cells as shown by class can be subsequently accessed. At step 416 JVM([) 

324a-324c. The size of any block can be dynamically then releases the write lock and class(N) is registered in the 

adjusted based on the size of the stored Java class. The link 25 shared memory pool 

position of the class within the shared memory pool 280 *JSS2i h . ™m TT y P ° 0L " * 

w . . , „ appreciated that JVM(I) and JVM(J) are both running simul- 

Managing the class cells as shown in FIG. 8 offers the taneously on system 112 (or could be the same JVM) The 

following advantageous. Class data does not have to be above determination is typically done by an instruction 

stored contiguously in memory 310. Also, a class cell can whose function is to establish classfN) for the JVM During 

contain boles and therefore not all the data needs to be the establishment function, before the class is written into 

present. This is especially useful when reassembling PDUs. memory, a check is first done to determine if the class has 

Also cells can be shared between class cells so that copying already been established in the shared memory pool by 

data from one class cell to another is done by maintaining another JVM. At step 420, if class(N) exists in the shared 
references and reference counters instead of physically 40 memory pool, then JVM(J) requests and obtains the read key 

copying the data. Adding data to and removing data from a for class(N) from the JCM. At step 422 JVM(J) then 

class cell can be done without physically copying or moving accesses class(N), as needed, from the shared memory pool 

the class cells contents. These features lead to a zero-copy instead of copying its own instantiation of classfN) in 

architecture, provided that the same memory management memory. At step 424, JVM(J) then releases the read key for 
techniques are also used by the device drivers and the 4J class(N) when done with this class. It is appreciated that 

d !! a,led e TP le f «"? manner in wbich «■* steps 418-424 can be repeated for other JVMs that are 

fnrfh h I ^ mampulatcs tbc class cel1 data 15 8 iv6D simultaneously running on computer system 112. Memory is 

runner oeiow. thereby saved because each JVM that needs class(N) can 

Without class sharing of the present invention, it is share the instantiation of this class as established by JVM(I) 
difficult to invoke several JVMs for memory-limited devices 50 without copying its own version. 

such as set-top-boxes, PDS, screen phone, etc. However PersonaUava uses a Unix-like file system for class load- 

toese devices need to support multiple applications based on fag. Because most RT operating system platforms do not 

Java. The JavaLayer's solution is to support multi- support the Unix-like system, the JavaUyer framework 

applications on one JVM. The technique for supporting supports a general file system which is mapped to the real 
multi-apphcahons on one JVM is to prevent the global 5S device drivers. The class mapper 175 (FIG. 4) is designed to 

classes or static classes from betng written by more than one support most standard storage drivers such as remote file 

nrn^H^ e Th Pn r 0r V \ d ° DOt 5Upp0rt *» systems for Inl6rnet flles or a Mini Disk system for local 

protection. The JavaLayer of the present mvention provides media in the SMAP (Single Media Active Project) group and 
a wnte-lock (WL in short) for each class cell. These are is analogous to a VFS layer in Unix 

maintained by toe shared lock 260 of FIG. 7. 60 Current , ^ ^ ^ 

As shown a FIG. 9, the JCM 270 locks the class cells The fitst type is Local medias, such as Mini D lS ta£s 

which are static classes or static variables to restrict the CDs. Each of the media has its own storage system The 

write-right. It gives the wnte-nght to the object which is second type is Internet-based hosts. The classes can be 

writing the static classes. JavaLayer allocates the class cell stored in a local or remote host server which is linked to the 
to the static classes with one wnte-lock (WL), which is used 65 target board by the networking. The tbird type are ROMs 

to record the object name. The highest priority is given to the The basic system classes and AWT classes are romized to the 

writing object to prevent dead lock. , a ,get board. Whatever medias the platform uses for storage 
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of the Java classes, a standard retrieval API is necessary for 
the JVM to access the classes. JavaLayer framework pro- 
vides a Mapper 175 which supports standard APIs for class 
management. 

The native software dealing with the hardware runs on the 
mAV metaspace 230 (FIG. 5 and FIG. 6). JavaLayer com- 
municates with these devices by using a Dispatcher class 
145 (FIG. 3). The standard class loader API is defined in 
Table I. For example, Table II illustrates an exemplary 
mapper that is designed for a remote file system mapping to 
the Unix-like file system. 

TABLE I 

class Unix-FileSystem { 

FlLE'fopen(const char "filename, 

const char "type); 
size_t firead(void " ptr, size_t size, 
size_t nitems, FILE "stream); 



12 



15 



} 



TABLE II 



typedef struct functab { 

char* name; 

void* ftlnc; 
} flinctab; 

flinctab Mapper » { 

{ "fopen 15Unix_FfleSystemFIPvUiPUr, rfe_open}, 

{ w fopen_15Unbt_FileS>*stemFIPvrjiPUr, miniDisk_open}, 
{ "fopen_15Unix_JJ , ileS>-steinFIPvUiPUi", flashRom_open}, 



} 



A mapper generator is designed for the automatic mapper 
generation by setting JVM class loader type. 

Communication Management Using the Shared 
Memory Pool 

Communication management using mAV's communica- 
tion mechanisms is now discussed. The shared memory pool 
280 can be used for message passing between applications. 
For instance, a native application can use the JavaLayer to 
communicate with a Java application. The JavaLayer frame- 
work supports communication between Java execution 
spaces and native applications running on AVIOS or some 
other metaspace in Aperios using the Dispatcher 145. The 
Dispatcher class 145 organizes programs as a collection of 
actions, each of which is invoked upon receipt of a message. 
A program registers a set of methods which the dispatcher 
calls in the context of its threads when a message arrives. In 
addition, a Java Dispatcher class 145 can be extended to 
support Java and can be used for AV applications. For 
instance, JVM can support an API that accepts the Dis- 
patcher 145 from the Aperios operating system 150 and 
invokes itself so that it can run in the application (JVM). The 
API interfaces between the JVM and the operating system 
150 (FIG. 4). 

Refer to FIG. 11. Within the communication method of 
the present invention, real time coordination is allowed both 
between JVM and native applications and between JVMs 
via the shared memory pool 280 for an embedded system. 
FIG. 11 illustrates an example system 510 for coordination 
between a JVM 130 and native applications 516. In this 
example, Home Audio/Video Interoperability (HAVi) appli- 
cation 516 needs to download a Device Control Module 
(DCM) 512 to install a device and control it. HAVi 516 first 



runs an application 514 and this application 514 needs a new 
device. Therefore, HAVi 516 downloads the device DCM 
512, as shown by 520, and stores it in the shared memory 
pool 280 of the present invention via interface 526. After 
5 that, HAVi 516 informs the JVM 130, as shown by 524, to 
run the DCM module to install the new device. The JVM 
130 then accesses the module that is stored in the shared 
memory pool 280 via 528. 
In the above fashion, the shared memory pool 280 is 
10 providing a message communication pathway between the 
native application and the JVM. Typically, the message from 
the native application to the Java application is processed 
using help from the operating system's (e.g., Aperios) mes- 
sage passing abilities. A target code in the message can be 
used to identify whether the message is for a Java applica- 
tion or for a native application. If the message contains a 
Java code, then the operating system will communicate with 
the JVM. 

HAVi 516 of FIG. 11, the shared memory pool 280 and the 
JavaLayer 160 interface with the operating system 150 and 
the JVM 130 interfaces with the JavaLayer 160. Havi 516 
can access or destroy contents of the shared memory pool 
280 via interface 526. The JVM 130 can run and access 
information of the shared memory pool 280 via interface 
528. JavaLayer 160 provides management via the JCM 270 
as represented by interface 530 in FIG. 11. Associated with 
JavaLayer 160, there is the shared memory pool (SMP) 
manager, also called JCM 270 and a JVM manager. 

In accordance with this example, the JCM 270 provides 
the following services as shown in Table III below. 

TABLE III 



20 



25 



30 



Service 






35 Value 


Parameters 


Return 


SMPManager::GetSMP 


(size) 


MemorylD 
size 


SMPManager:: GetsMpFreeSize 


SMPManager::GetSMpStatus 


(MemorylD, 


RUN, 


40 SMPManager::GetSMPDestroy 


Offset) 


COMPLETE, FAIL 


(MemorylD) 


FAIL, 






SUCCESS 



The JVM manager provides the following services as 
shown in Table IV below: 



45 



TABLE IV 



Service 



Parameters 



Return 
\fctue 



50 JVJMManager::Execute 
JVMManagcr::SctStatu5 



(ModuIeName, MemorylD, FAIL, 
Offset), SUCCESS 
(MemorylD, Offset, Status) FAIL 

SUCCESS 



55 



60 



65 



FIG. 12 and FIG. 13 illustrate an example of coordination 
between several JVMs using the shared memory pool 280 of 
the present invention. With reference to FIG. 12, a first JVM 
130a and a second JVM 130b are shown interfacing with the 
JavaLayer 160. The first JVM 130a is receiving a video 
stream from a broadcasting source 546 and the second JVM 
1306 is playing the video stream simultaneously 548 to 
some rendering device (e.g., a DTV). The first and second 
JVMs are communicating the video stream 544 using the 
share d memory pool 280, with the first JVM 130a writing 
into the shared memory pool 280 and the second JVM 1306 
reading from the shared memory pool 280. In home 
networking, the first JVM (called JVM1) 130a is running an 
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application 546 for receiving the video stream fro m a 
broadcast and decoding the stream in the shared memory 
pool 280. The second JVM (called JVM2) 1306 was receiv- 
ing user's control and playing the stream. 

FIG. 13 illustrates a timing diagram of events occurring 
between the coordination of the first JVM 130a (on the left) 
and the second JVM 1 306 (on the right). At 562, the first 
JVM 130a receives the video stream and by 574 it saves this 
information into the shared memory pool (SMP) 280. The 



14 



a new running thread and the heap size. It implicitly initial- 
izes basic Java Classes, with pJava version information and 
also checks whether the version is compatible with the 
implemented JVM or not. With the "share" parameter, the 
WM does not initialize Java Classes but shares Class Stack 
with another JVM pointed by param share. Two JVMs, 
which are expected to share the classes stack, should be 
compatible versions and synchronized. This parameter can 
be pointed only at the creating time. Otherwise, the JVM 



n/ivyt nn*. a I V 1 7 T r uc P uimcu om y ai ine creating time, utnerwise, the JVIv 

h^fSSJ^St ^T^^JW* 10 ° WDS aD indc P™ dcnt Class Stack by calling to initialiseja 

584 ^ status " U P° n successful completion, the pointer to the new 

K^^^^!^5?°^ to ^ y ^ TO 15 JVM is returaed * Otherwise NULL is Jura, 

through the Internet as instructed by user control 570. At ™. . . . .. „ n ( , 

566, the first JVM 130a receives and sends back a stream ™! ? ynla ? ini r Ua li^VMclass(class, method) is used to 

590 in response to the Internet game. At interface 586 T ! * ^ U the daSS akeady existS m 

information is both saved and retrieved by the first JVM memory pool 280, then this command does not 

130a. The second JVM 130Z> then supports game playing , n generate an ^ r a C0 W of the class ***** shared 

572 by interfacing with the SMP 280 to provide interoper- mcmor y P°° l 280 but rather uses the copy that already exists 

ability 588. In all cases of FIG. 13, the shared memory pool , ? f the u class does not exist the shared memory 

280 is used as an intermediary in the communication P 001 ;^ this command generates the copy of the class into 

method. tne snared memory pool and registers the class with the JCM 

Event Handling is described. DeviceEvent is the base 25 COmmand exe ^^aC lass( ) is used for message 

interface for events in the JavaLayer framework. In order to S ™ S 



support the Java AWT, event model, an implementation of 
DeviceEvent, is required to sub-class java.utii.EventObject. 
Device events asynchronously deliver information about 
keyboard input, screen touch, remote control. To receive 
events, an object implements the device listener interface 
and uses the "add device event" method to the event queue, 
JavaLayer provides an deviceEventMapper to map different 
devices to the standard event handling interfaces. The defi- 
nition is shown in the list of Table V. 

TABLE V 

cla$sAV_EvenHandling { 
Position x, y; 
Evenffype eviype; 
Eveat * queue; 

void (*deviceEvenMapper(DeviceID dID)) (void); 

} 

typedef struct functab { 
DevicelD dID; 
void* func; 
} Device_Func_tab; 
Dcvicc_Juuc_tab DeviceMapper - { 
{Keyboard, KeyboardHandling}, 

{RemoteControIler, RemoteControllerHandling}, 
{TouchPanel, TouchPanelHandling}, 

} 



An example implementation of a JVM within the AV/OS 
operating system is presented below. The syntax of the list cc 
of Table VI is described as below. 

Regarding the syntax address server, the JVM uses the 
host of "serverHost" as a server to download classes. The 
target devices connect with the host by the Internet. Regard- 
ing the syntax version ver, this records the WM version 60 
information. Regarding the syntax stack stackentry, this 
records the JVM stack entry. Regarding the syntax JVM 
4 share, this is the shared JVM point. If it is not NULL, the 
stackentry is NULL. The size_J heap is the heap size for this 
JVM. Here, the "ClassLoader" is shared. 65 

The syntax static JVM ♦ Create (size_t heap, Version ver, 
uint32 threadopts, JVM *share) constructs a new JVM with 



Regarding the syntax, status Destroy( ), it is used for 
destruction, all activities in the JVM are explicitly termi- 
nated and destroyed. The initialized class stack also is freed. 
3Q If there are any other JVM is sharing class stack with the 
current JVM, the destruction is pending until the release of 
the class stack. The syntax * void executejavaClass (char * 
className, void * args[]) represents the method for notation 
of running "application class." For example, the JVM runs 
the application bytecode class "HelloWorld .class", prints out 
"Hello World" if it is used as: 

executejavaClass ("HelloWorld", "main") 
TABLE VI 

class JVM { 

static JVM * Creat( ); 

static JVM • Crcat(sizc_t heap, Version ver, 
JVM *share, Address server, 
Class Loader cL_type); 
Version ver; 
Stack stackentry; 
JVM * share; 
size_t heap; 
enum ClassLoader { 
MD, 

rfe_F[LE 
50 ROM, 

Download 
} cl_type; 
Address server; 

InitializeJVMclass(class, method); 
executeJavaClass( ); 
status Destroy( ); 
void SetServer (Address addr); 
Stack inittaliseJava Class (uint32 level); 
AV_EventHandJing *event; 
Unix^RleSystem fileHandling; 



35 



40 



45 



An implementation of PersonalJava (pJava) is discussed. 
A combination example of the modules of JavaLayer is 
pJava. It is appreciated that pJava is a Java™ API and Java 
Application Environment for networked applications run- 
ning on personal consumer devices. Running pJava on 
Aperios is targeted for platforms such as set-top boxes which 
are composed of Aperios real time operating system, down- 
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load run time environment, Internet-based web browser and 
home network. 

The list of Table VII shows an example of pJava which is 
created with heap size 2097144, PersonalJava 1.1 
compatible, and running an application called "Browser". 5 

TABLE VII 

pJava = JVM::Creat(2097144, pJaval.l, 

NULL, 0, r£s__FILE); 
pJava -> SetServer (43.135.113.83); 10 
pJava-> initial izeJVMclass( ); 
pJava-> executeJavaClass (Browser", "main"); 
pJava-> executdavaClass("SmapApp]et.Class", "run"); 

The preferred embodiment of the present invention, a 
computer-implemented method and system for sharing Java 
classes across multiple Java virtual machines on the same 
computer system and a method for communication between 
Java and native applications (or between two or more 
JVMs), is thus described. While the present invention has 
been described in particular embodiments, it should be 
appreciated that the present invention should not be con- 
strued as limited by such embodiments, but rather construed 
according to the below claims. 

What is claimed is: 

1. In a computer system, a method of sharing Java classes 
comprising the steps of: 

a) a first Java Virtual Machine (JVM) loading an instan- 
tiation of a first Java class into a shared memory pool; 

b) registering a name of said first Java class into a name 
table that is used for said shared memory pool; 

c) querying said name table on behalf of a second JVM to 
determine if said first Java class is stored in said shared 
memory pool, wherein said second JVM is operating 
on said computer system simultaneously with said first 35 
JVM; and 

d) said second JVM accessing and utilizing said instan- 
tiation of said first Java class from said shared memory 
pool in lieu of creating a separate instantiation of said 
first Java class for its own use. 

2. A method as described in claim 1 further comprising the 
steps of: 

said second JVM loading an instantiation of a second Java 

class into said shared memory pool; 
registering a name of said second Java class into said 

name table; 

querying said name table on behalf of a third JVM to 
determine if said second Java class is stored in said 
shared memory pool, wherein said third JVM is oper- 
ating on said computer system simultaneously with 
said first and said second JVMs; and 

said third JVM accessing and utilizing said instantiation 
of said second Java class from said shared memory 
pool in lieu of creating a separate instantiation of said 
second Java class for its own use. 

3. A method as described in claim 1 wherein said step a) 
comprises the steps of 

al) accessing a write lock associated with said first Java 
class; 

a2) granting write access of said first Java class to said 
first JVM when said write lock associated with said first 
Java class becomes free; and 

a3) said first JVM writing said instantiation of said first 
Java class in response to said step a2). 

4. A method as described in claim 3 wherein said step a3) 
comprises the steps of: 
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loading said instantiation of said first Java class into 
blocks of said shared memory space and registering 
offset and size information regarding said blocks; and 
linking said offset and size information with said name of 
said first Java class. 

5. A method as described in claim 1 wherein said step d) 
comprises the steps of 

dl) accessing a read lock associated with said first Java 
class; 

d2) granting access of said first Java class to said second 
JVM when said read lock associated with said first Java 
class becomes free; and 
d3) said second JVM accessing said instantiation of said 
first Java class in response to said step d2). 

6. A method as described in claim 1 wherein said first 
JVM has an associated first Java application and wherein 
said second JVM has an associated second Java application. 

7. A method as described in claim 1 wherein said first Java 
class is a Java IO class. 

8. An embedded computer system having a processor 
coupled to a bus and a memory device coupled to said bus 
wherein said memory device contains instructions stored 
therein that implement a method of sharing Java classes, said 
method comprising the steps of: 

a) a first Java Virtual Machine (JVM) loading an instan- 
tiation of a first Java class into a shared memory pool; 

b) registering a name of said first Java class into a name 
table that is used for said shared memory pool; 

c) querying said name table on behalf of a second JVM to 
determine if said first Java class is stored in said shared 
memory pool, wherein said second JVM is operating 
on said computer system simultaneously with said first 
JVM; and 

d) said second JVM accessing and utilizing said instan- 
tiation of said first Java class from said shared memory 
pool in lieu of creating a separate instantiation of said 
first Java class for its own use. 

9. A computer system as described in claim 8 further 
comprising the steps of: 

said second JVM loading an instantiation of said second 

Java class into said shared memory pool; 
registering a name of said second Java class into said 
name table; 

querying said name table on behalf of a third JVM to 
determine if said second Java class is stored in said 
shared memory pool, wherein said third JVM is oper- 
ating on said computer system simultaneously with 
said first and said second JVMs; and 
said third JVM accessing and utilizing said instantiation 
of said second Java class from said shared memory 
pool in lieu of creating a separate instantiation of said 
second Java class for its own use. 

10. A computer system as described in claim 8 wherein 
said step a) comprises the steps of 

al) accessing a write lock associated with said first Java 
class; 

a2) granting write access of said first Java class to said 
first JVM when said write lock associated with said first 
Java class becomes free; and 
a3) said first JVM writing said instantiation of said first 

Java class in response to said step a2). 
U. A computer system as described in claim 10 wherein 
said step a3) comprises the steps of: 

loading said instantiation of said first Java class into 
blocks of said shared memory space and registering 
offeet and size information regarding said blocks; and 
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linking said offset and size information with said name of 
said first Java class. 

12. A computer system as described in claim 8 wherein 
said step d) comprises the steps of 

dl) accessing a read lock associated with said first Java s 
class; 

d2) granting access of said first Java class to said second 
JVM when said read lock associated with said first Java 
class becomes free; and 

d3) said second JVM accessing said instantiation of said 
first Java class in response to said step d2). 

13. A computer system as described in claim 8 wherein 
said first JVM has an associated first Java application and 
wherein said second JVM has an associated second Java 
application. 

14. A computer system as described in claim 8 wherein 
said first Java class is a Java 10 class. 

15. In a computer system, a method of communicating 
between applications comprising the steps of: 2Q 

a) a first Java Virtual Machine (JVM) loading an instan- 
tiation of a first Java class into a shared memory pool; 

b) registering a name of said first Java class into a name 
table that is used for said shared memory pool; 

c) querying said name table on behalf of a second JVM to 25 
determine if said first Java class is stored in said shared 
memory pool, wherein said second JVM is operating 
on said computer system simultaneously with said first 
JVM; 

d) said second JVM accessing and utilizing said instan- 30 
tiation of said first Java class from said shared memory 
pool in lieu of creating a separate instantiation of said 
first Java class for its own use; and 

e) a first Java application of said first JVM communicat- 
ing messages to a native application by writing said 
messages into said shared memory pool and said native 
application reading said messages from said shared 
memory pool. 
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16. A method as described in claim 15 further comprising 
the step of said native application communicating messages 
with said first Java application by writing said messages into 
said shared memory pool and said Java application reading 
said messages from said shared memory pool. 

17. A method as described in claim 15 further comprising 
the step of said first Java application communicating mes- 
sages with a second Java application of said second JVM by 
said first Java application writing said messages into said 
shared memory pool and said second Java application read- 
ing said messages from said shared memory pool. 

18. A method as described in claim 15 wherein said step 
a) comprises the steps of 

al) accessing a write lock associated with said first Java 
class; 

a2) granting write access of said first Java class to said 
first JVM when said write lock associated with said first 
Java class becomes free; and 

a3) said first JVM writing said instantiation of said first 
Java class in response to said step a2). 

19. A method as described in claim 18 wherein said step 
a3) comprises the steps of: 

loading said instantiation of said first Java class into 
blocks of said shared memory space and registering 
offset and size information regarding said blocks; and 

linking said offset and size information with said name of 
said first Java class. 

20. A method as described in claim 15 wherein said step 
d) comprises the steps of 

dl) accessing a read lock associated with said first Java 
class; 

d2) granting access of said first Java class to said second 
JVM when said read lock associated with said first Java 
class becomes free; and 

d3) said second JVM accessing said instantiation of said 
first Java class in response to said step d2). 
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